Online transaction processing (OLTP) applications are used for databases that provide ACID (high atomicity, consistency, isolation and durability) consistency properties, but are increasingly working in loosely coupled “AP” (availability, partition tolerance) settings where consistency guarantees are not strong. In particular, when a transaction inserts rows and commits, the application expects one of three returns: a) transaction success, b) transaction rolls back (e.g., constraint violation), c) transaction status unknown (usually due to a driver or connection error, and an application can issue queries to check the status). But in any case, after a commit, in conventional ACID database management systems (DBMSs), subsequent reads see the same answers a (i.e., monotonic behavior). If one query sees the inserted rows, then subsequent queries will also see those inserted rows, consistently (for return c), an app has to issue a read to find out status).
In an AP environment (e.g., with many NoSQL (non-structured query language) DBMSs), there is a fourth return, referring to a problematic return state: d) transaction status may not be settled yet. This happens when the node (where a node is a client device, a server, or peer device) running the transaction has sent the changes/inserts (as a log message) to other replicas, but has not heard acknowledgements from them (indicating that they received or accepted the changes). In this state, subsequent queries see unpredictable behavior. A first query may not find those rows—because they have not replicated yet to sufficient number of replicas (according to a quorum policy). But a later query may find those rows.